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ABSTRACT 

eW  *®atures  added  to  SAIL#  an  ALGOL  based  language  for  the  PDP-10, 
apf  discussed,  The  features  Include!  procedure  variables;  multiple 
Processes;  coroutines;  a  limited  form  of  backtracking!  an  event 
mechanism  for  I nter-process  communication;  and  matching  orocedurss,  a 
new  way  of  searching  thr,  LEAP  associative  data  base, 
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introduction 


Progress  In  Artificial  Intelligence  ha®  traditionally  been 
accomDan!ed  by  advanc#s  In  soeolal  purpose  programming  teohnloues  and 
anguaflas,  Virtually  a  |  I  of  this  deve  |  op.ntnt  has  been  concentrated 
In  languages  and  systems  oriented  to  list  Drooesslrg.  As  the  efforts 

-  f  °  *!,Inte| 1 ‘9?no*,  f ®3#af ohars  began  to  turn  from  purely 

symbolic  problems  toward  Interaction  with  the  real  world,  oortaln 
features  of  a|sebraIo  languages  beoame  desirable.  There  were  several 
attempts(not«b|y  L|SP2  and  FORMULA  ALGOL)  to  combine  the  best 
features  of  both  kinds  of  language.  At  the  sane  time,  disigners  of 
I anguages  began  to  Inolude  features  for  non-numer  I oa I 
computation.  No  new  general  purpose  language  without  some  sort  of 
list  processing  facility  has  been  suggested  for  several  years.  We 
have  fouowed  a  tack  somewhat  different  from  either  of  these  In  the 
design  of  SAIL  and  In  Its  subsequent  modifications, 

The  starting  point  for  the  development  of  SAIL  was  the  reoognlzed 
re0°^ . . T  a  language  Incorporating  symbolic  and  algebraic 

capabilities,  primarily  for  Hand»Ey$  reeearoh,  The  problems  are 
somewhat  similar  to  those  In  Computer  Graphlos  and  one  of  us  had  just 
developed  a  language,  LEAP  C4J,  for  such  app| (cations,  After  an 

!J*#*°*  t?„5?Hestly  6va|uat!  alternative  techniques,  we  decided  that 
the  associative  processing  features  of  LEAP  w9re  the  way  tb  go.  There 
are  Important  dlfferenoes  between  LEAe  and  the  first  SAIL,  (Primarily 
In  input-output,  string  manipulation,  and  Implementation),  but  these 
f]ot7  r®  I  eyant  here,  It  Is  essentially  this  system  for 

?  ?h,.is  distributed  by  DECUS  and  Is  being  used  for 

Artificial  Intelligence  and  other  research  In  a  number  of 

laboratories, 

I£!?nM-i9,2a,„SAlL  m5t  oup  n#eds  for  *b°ut  two  years  before  requiring 
serious  change,  Then  w«  began  tc  face  the  ofobleS  of  puttfnS 

together  a  hand-eye  system  whloh  was  much  bigger  than  tha  available 

main  memory  and  whiqh  did  not  lend  Itself  to  a  statlo  overlay 

!J|Uwtrr*1  i  i*0!!P  s°|ut,on  Involves  a  number  of  language  additions 
whicn  raollltate  the . treatment  of  Jobs  under  the  time-sharing  system 
?s  ?«!  1  2  oooDeratlng  seouentlal  processes,  and  has  been  described 

in  [OJ,  The  three  main  additions  war*  t  a  monitor  for  user  oontrol 

and  debugging,  a  shared  data  facility,  and  the  Intrbductlon  of 
message  procedures,  The  shared  data  fftolllty  makas  uee  of  the  second 
!a'°®a Tlon  refl later  of  the  PDP-10  to  allow  Jobe  tc  aocess  a  common 
9 1  JJ!  fata  araa  *  n®Jural  and  effloler.t  manner,  The  message 

Procedures  are  the  main  meohanlsm  for  asynchronous  communication  and 
oontroi  between  Jobs,  A  message  prooedure  Is  a  procedure  In  one  lob 

"h'c*  *a"  b!.*JnVukeci  , f  rom  *n°ther  Job.  Control  Information 

associated  with  the  Invocation  can  provide  the  effect  of 

subroutines, coroutines, paral  lei  Droceeses, events,  and  a  variety  of 
ether  disciplines,  These  mu  1 1 1 -task  I ng  modifications  to  SAIL  have 


In  programming  non-detepm I n I st I c  algorithms,  parallel  Processes#  will 
t>e  dlscU3s®d  Uter  In  this  paDer, 

In  general  the  state  of  a  SAIL  computation  Includes  the  ourrent 
control  environment,  the  input  and  output  whloh  have  been  requested, 
the  contents  of  the  LEAP  associative  store  and  the  contents  of  all 
variables,  New  SAIL  has  features  which  will  help  handle  the  last  of 
these  components*  the  oontents  of  variables, 


We  normally  do  not  want  to  have  the  values  of  all  variables  "backed- 
up  when  we  switch  between  alternatives.  One  reason  Ta  the^t  It  Is 
often  useful  for  one  alternative  to  communjoate  oertaH  nieoas  of 
Information  It  has  acaulred  to  the  other  alternatives,  This 
Information  Is  usua)ly  saved  In  certain  variables,  If  we  backup  those 
variables,  we  lose  the  Information,  Another  reason  for  nbt  backlng-uo 
a|l  variables  Is  that  often  only  a  small  subset  will  have  meaning  for 
more  than  a  single  alternative,  and  It  Is  very  costly  to  baok  uo 
large  amounts  of  data  whloh  may  not  be  relevant  for  the  other 
alternatives,  Therefore  we  have  Implemented  ways  of  s§vlnd  the 
values  of  specific  variables  and  then  restoring  them  at  a  late?  time. 


§f!fS5?ri2ShmSfh!(!ii2  iS.fHSaoS".t!!8wn?SiL,Sn!:0?Jii.REc»^?§Ri 

text",  A  context  oonslsts  of  a  set  of  references  to  variables  and 


The 

and  _  , 
"context 
th«|r  values. 


We  save  the  contents  of  variables  by  means  of  REMEMBER  statements, 

REMEMBER  ( I »  J,a[3] )  IN  context!.* 

This  statement  w0u|d  save  the  values  of  "|",  "J",  ,  "aC3]"  In  the 
context  named  "context!",  If  any  of  these  variables  had  been 
Previously  saved  In  "context!",  tb*  o  |  d  values  Would  be  lost, 


An  alternate  form  of  the  REMEMBER  statement  1st 

REMEMBER  all  in  oontextlJ 

The  current  value  of  each  variable  which  has  been  remerriDered  in 
"contextl”  would  replace  the  value  that  was  Previously  stored  there, 

The  RESTORE  statement  also  has  two  forms,  The  first  has  an  argument- 
list. 


RESTORE  ( J,aC3] )  FROM  context!* 

ISi?Ca??ou^ifs,!S5hH§?St,5a  "l?S.45?.5i:autlT?S?n  MSt  sJS5t.5?.<,'ffi8 

values  saved  for  those  arguments  " remember ed«,  would  be  restored  to 
the  appropriate  variables, 
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f*®8*^*'*  to  assemble  and  modify  |arge  oolleotlons  of  Jobs 
with  a  minimum  am0unt  0#  »tt*ntlen  te  system  problems. 


r  ffctop®  -h«ve  99®bjned  reoently  to  oause  us  to  maki 

’leiTit,.9!*.*  ra  ,°*,Ion“  to  t”  Uuijf.tMK' 

wtthi.  !\?:n,ih,,!;c!?d  «  b*  «  i'«t  .1?  u..fui 


ab  |ity  to  assemble  large  oo  leotlone  of  routines  brought  us  to  the 

SSI;  i!ftl!°lTIh!B: of  th*  00:#  D:?b,#"5 of  int.VTi.5Sc2  : 

what  le  the  right  seouenoe  of  aotlons  for  carrying  out  •  given  task 
.n  a  pertloular  environment,  This  strategy  problem  Is  ourrentl'y  very 
bobular  and  Is  the  driving  'area  behind  min*  \t  £11 

tllh  "  lIn?um°*T  f*r  **■  t  S  f  to  I*  I  Intelligence,  Our  of  the 

Dppb  I *®  Is  cgeiiHhat  unorthodox  end  meri  ts  »om«  dissuasion, 

a*  K  -  In  faction*  gf  ths  mein  gotis  of  a  ■treteov  tn  t n 

Qan  enough  rnformetton  to  carry  out  the  tea*,  Ah  atfdltTona*  problem 
irks*i  In  ritourcf  allocatloni  even  If  jn  exhaustive  «*»;,»  -.f  +h * 

environment  hU  I  yield  .  solution,  It  W  w?  !!  !I  I!  'ffi'S&M&SS 

e^flhl  mr  fe^flSFS  *  H<?rt  Cause  ue  to  vfew  the  strategy 

niil  ss  Inherently  Involving  numerical  estimate!  of  p^ebebl  [I* I a>! 

I  liLt  comoleti  dlsouealon  gf  these  leiuef  ft  osyond  ths 

!_  3afl,r  f  but  the  recent  SAIL  mod  I  float  I  cm  nave  been 

fn'rJi^cr^  by  cur  model  of  the  sicategy  ofeblem, 

ir  Intended  ^.facilitate  the  design 

7'  "'D»rams  Tor  the _ eonstruct I  on  ana  execution  of  strategies  fo. 

•; ht::acnt,rt°hnIr,th  <*"  *?p,d*  ^  ^oiutii;  *r*  b.iSirtiS2}?!d  ;s 

Holler  Iha  lanau  SUtH«W?aW  "##00f1C,ntrit#  0n  th?  0pM"*'  theme, 
pow!r  Sf  t5ln  I!  !' *  d  ?l?n  conoemed  with  expanding  the 

!°.  I.?’iS4,L  o«n«r»l  buropsa  language  aa  oopoaed  to  davalpplng 

faatu^I  n«r!n*riiV?t,B'  2T!-°r  tlc,l  d,bl01’  oonatraint  was  that  tha 
OHfo^!n«!  ,»  J  i-  ,r0  h'dd,n  »*»rba.da  or  appreolablv  deorada  tha 
“Hid  I  SIt  f.5  ?!r!"  notul?*Jlos  “»•  tha*.  Ha  ballav.  wa  have 

addltlol.  *..?!  J  Ui!“  ?ildh  **,t  dUr  d,*,tn  Tha  major 

!  «  .i?n9  ar^  backtracking,  orooedyre  variables,  matohlno 
Procedures,  and  a  general  mu  1 1 1 -task  I  no  facility, 

STATE  SAVING  AMD  BACKUP 

In  ofd*r  t o  try  several  afrfirsnt  Mtamatlve  ]«  u  hfa*K 

oao.aa.fV  to  aav,  ,h,  ourr.nt  .tat.  of  !5i  »«Su«ScTon?"TnSa.  I f  “I 
f|r,t  attamot  ooaa  mot  ouoo.tdi  h«  mar  "back  ue*  ,md  try  ora  of  rHr 
alt.rh.tWn,  Ha  may  al.oVl,"  1  .nil.  1 : 1IL.I  in!’ 

Sut  HHIhtlr  »l  onl; |untfl  It  "*  I Man.  tha  moat  .rornlaWg, 
nut  retaining  the  potion  of  resuming  ft  |it*f  If  me  other 

alternatives  do  not  srove  to  be  oetUfectory,  Another  technlaue  used 


> 


> 


> 


> 


> 


ft 


l 


I. 


* 


l 


In  crossing  non- term  I  n  I  >t  I  c  algorithms,  parallel  processes,  will 
be  dlscuss®d  later  in  this  paDer* 

SrsSi^aS,^: 

variables,  New  SAIL  has  features  which  will  hale  handle  the  iasx 
th«s®  components!  the  contents  of  variables, 

0i  iiitIMi  *aflt#|ei  and  than  re.toflrn  them  at  a  later  tU., 
the  |  r  values, 

We  save  the  contents  of  variables  by  means  of  REMEMBER  statements. 

REMEMBER  ( I  #  J # »C33)  IN  contsxtl) 

i'i'A»v'x&¥  5ssas.««»:  ““;*?Vi;iHo;isfi::!ii;"hiinb*!,B 

previously  saved  In  "contextl".  tbe  o|d  values  would  be  lost. 

An  alternate  form  of  the  REMEMBER  statement  1st 

REMEMBER  ALL  IN  oonttxtl J  *  _  .  , 

The  current  value  o*  each  variable  which  has  bsen  remembered  ,n 
"contextl"  would  re0lace  the  value  that  was  orsvlously  stored  th  , 

The  RESTORE  statement  also  has  two  forms.  The  first  has  an  argument- 
list. 


RESTORE  <J i aC33 )  FROM  context!! 

This  wog|d  search  oontextl  f,?2fiam&ii?t§^US3T ?fi?n  tRat  ^oootex?,  rfRe 

Hrf.i'forthSU*  .?sS.:ss:,*?KSii.*riis.  8«sw  ».•  t. 

the  appropriate  variables. 
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f 


The  other  form  of  the  RESTORE  statement  1st 


RESTORE  ALL  FROM  context!! 

nam|dWcon?ex^est0re  the  cor,tenta  of  all  variables  saved  within  the 


Thes®  n  e  w  features  seed 
state-sav|ng  without  the 
of  t^e  entire  state  or 
some  other  programming  systems. 


J  .  ..  ,  .  A. 


tw  wruv  iue  vm  . 

Iarae  overhtgd  Imposed  bv 
Incremental  state-saving  as 

Am* 


autom«tlc  baokUD 
Implemented  In 


LEAP 


SaH  contains  an  associativa  data  system  oa||ed  LEAP  whloh  Is  used 
for  s  y  rr  fa  o  I  I  o  comoutat  I  ons  i  LEAP  Is  a  combination  of  syntax  and 
runtime  subroutines  for  handling  Items*  sets  of  Items  and 
assoc  I  at  l  ons# 


An  Item  is  similar  to  a  LISP  atom, 
during  exeoutlon  from  a  pool  of 
Items  may  be  stored  in  variables  ( 
elements  of  lists,  Or  be  assoo 


terns  may  be  dso|sr«d  or. obtained 
terns  by  using  the  function  NEW . 
temvars),  be  members  of  sets,  be 
ated  together  to  form  triples 


o  |  oii.en  <*3  vi  il3Vvf  w  v  Qggvv  in  %  w  v  wv 

(associations)  within  the  associative  store, 

A  set  |g  an  unordered  ool lection  of  distinct  Items,  Items  .may.be 
Inserted  Into  set  variables  by  "PUT”  statements  and  removed  from  set 
variables  by  '’REMOVE"  statements.  Set  expressions  may  also  be 
assigned  to  set  variables,  The  simplest  set  expression  Is  of  the 
form* 


(Itemi,  Item2,  I tem3  , , ,  ) 

which  represents  the  set  oonslsttng  of  the  denoted  Items,  More 
complicated  set  expressions  Involving  set  functions,  „sft  union, 
subtraction  and  Intersection  are  also  Provided,  Sets  are  stored  in  a 
oanon | ca  I  internal  form  which  ailowj  us  to  carry  out.  such  operations 
as  Intersection,  union  and  oompaclsoh  In  a  time  proportional  to  the 
lengths  of  the  sets  involved, 

Sets  are  deflolent  in  some  applications,  though,  because  they  are 
Unordereci,  Thus  wa  could  not  easily  try  different  alternatives  In 
order  of  their  exDected  utility,  To  remedy  th|e,  ap  well. at  provide  a 
mechanism  for  oreation  of  parameter  lists  to  1 nter prat  I  ve  i  y  called 
Procedures  (see  PROCEDURE  VARIABLES  below),  SAIL  now  oontalns  a  data¬ 
type  called  ’’list",  A  list  Is  simply  *n  ordered  sapuenoe  of  Items,  An 
Item  may  appear  m0re  than  once  within  a  |  1st,  Ligt  operations 
Include  Inserting  and  removing  speolflc  Iteme  from  a  list  variable  by 
Indexed  put  and  REMOVE  statements,  List  variables  may  also  be 
assigned  list  expressions,  the  slmoleet  of  which  Is  of  the  forml 

((Itemi,  item2,  I tem3  ,,,)) 

which  represents  the  expllolt  seauenos  of  denoted  items,  .  Other  list 
expressions  Include  list  functions,  oo  icatenatlon,  and  subllsts, 

Triples  arc  ordered  three  tuples  of  Items,  and.  may  themselves  be 
considered  Items  and  ooour  Tn  subsequent  associations,  They  are  added 
to  the  associative  store  by  executing  MAKE  statements.  For  example} 

make  use  *  planl  =  tasklj 
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The  three  Item  comoonents  o'  !h8”!Suie " '  ?esoeot  I  ye!  y!*Assoe  lat  I  one 

ERASE  us®  *  ol*nl  =  ANYl 

Each  Item  other  then  those  i[]Sdata-tyoe!0The”oataityoe  of  a 

SJI5J  'may  S“  ' 'Sh.Sk.d'' X  Ind  K-ut^n.  OATUMa  a . .  much  as 

variables,  For  evamolei 


0AT’JM(  It)  *-51 

H0U 1 0  cause  the  datum  of  the  I  tern  "It"  to  0.  replaced  with  "5". 

Sail  contains  »  oojpl 1  “ Jin!05!3? {? one? '  como i" at Unt '  As  ?s  ’the  custom 
,s  string  substitution  and  eond  t  onal  to  stand  'or  the 

UrTsr-^TiiHs:0?;::"^:  l-°"  «»■*  »» . 


8  (  1 1)  *•  5» 


procedure  VARIABLES 


r'sriJITSSS.^SliVK  fSIorllli^I 


o'  lt  ’  as,  "eae 1 1  v  m.de 

V,r  .rtlr.dl.l  fn;el  I  Iseno.  ■”  the  o'  eud" 

■  sal  ladle  foe  oomo j  '  **  “'‘“""SjseUura  ..rleile  megh.nl,*  unto"  'Its 
Msutacas  la  Ingl  It.ted  ■  L„P)h  r,,tures  o'  the  l*nSueoe, 

!»  «!««  «  . .  is’",a' 

3tat®fn®nts  of  the  form 

ASS  I GN ( < I t®m  expression). Procedure  sd®0 I f i cat  I on> ) 


wh®  r  ® 


Cprocedur,  so..l5lo.tlon>oU"du<or=o.dur.old>5lon>) 


For  Instance, 


ASSIGNS  xxx, baz) 


w0u|d  caus®  the 
toaether  with  a 
3tat®n®nt 


datum  of  I  tern 
oolnter  to  baz1 


xxx 
s  current 


to  contain  ft  description  of  baz, 
environment,  Similarly*  the 


ASSiGN(yyy*9ixxx)) 
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would  cause  yyy  to  be  made  Into  a  procedure  Item  containing  the  same 
Information  a8  that  In  xxx, 

In  addition  to  dynamically  soaolfylno  what  procedure  to  execute,  one 
would  a|So  Ilka  a  convenient  way  to  dynamical |y  specify  an  apoumant 
list  for  a  orooedu?e  call.  Thla  facility  la  Dpovlded  by  the  APPLY 
meoh*n I sffll 

APPLY(<orocedure  aoac I f I  oat  I oh>» <apBumant  llst>) 

whar«  <arflum9nt  list  >  lo  any  SAIL  list  and  may  be  omitted  If  the 
oroc«dure  has  no  parametera,  Fop  example, 

APPLY ( f oo ) 

AppLY  ( a ( x  x  x ) , | Istl) 

APPLY<9<APPLy(yyy)). <<x«y»x>>> 

Apply  uaes  the  Items  In  the  apflument  I  let*  together  with  the 

environment  Information  from  the  prooedure  Item  (or  from  the  ourrent 
epv | ronmenti  If  the  procedure  (s  named  explicitly)  to  „make  the 

eporoprlate  procedure  call,  If  the  oa I  led  orooedure  produces  a 
value,  that  value  w] | |  be  returned  ae  the  value  of  APPLY, 

P  roo«dura  I  terns  oermlt  a  great  deal  of  flexibility,  For  Inetanoe, 

the  us«r  can  say  things  like 


FOREACH  x  |  xeactlons  A  useex=f astenl ng  do 
BEGIN 

APPLY ( d <  x ) £ ( (board! , boar d2) ) )  I 
IF  togflther ( boar dl, boaedZ )  THEN  GO  TO  don9|ti 
END  l 
done  1 1 » 

This  would  searoh  the  1set.”aotl ons" , f or  any  ppooeduree  wblch,have 
been  asserted  to  be  useful  for  fastening  things  together  until  either 
the  list  le  exhausted  or  the  task  Is  successful |y  completed, 

MULTIPLE  PROCESSES 

The  control  structure  of  SAIL  was  originally  very  .muoh  like  that  of 
Algol  60  «•  that  (s  to  eay  block  struotured  and  orooedurf  oriented. 
Although  this  struotur*  Is  adeouate  for  many  Problems,  there  are  some 
eases  In  whloh  it  Is  unoomf or  tab  I y  restrlotlve,  In  hand-eye 
applications,  for  Instanoe,  there  are  freouent|y  moduips  of  oode 
which  are  more  or  less  mutually  Independent  but  that  wish  to  call  on 
each  other  for  various  servloes,  Similarly,  one  may  wish  to 
Investigate  several  possible  strategies  At  onci#  with  the  results  of 
one  computation  perhaps  Influencing  the  course  of  others,  In  such 
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cases,  it  Is  much  more  natural  to  thin*  of  (and  write)  these  modules 
as  eo-rou*!nes  or  Independent  processes  rather  than  _as  nested 
DroceduPe  calls,  To  some  extent*  message  procedures  provided  the 
desired  facilities,  with  each  Job  acting  a3  a  seoarate  process,  This 
solution  has  some  father  severe  drawbacks*  since  the  overhead 
Involved  In  switching  oontrol  from  Process  to  prooess  and  In 
Interprocess  communication  Is  so  high  that  close  Interaction  becomes 
Prohibitively  expensive,  On#  of  our  goals  In  Providing  new  control 
facilities  was  to  make  possible  the  close  cooperation  of  many  small 
to  medium  sized  processes  within  a  single  Job  without  Imposing  an 
excessive  overhead  either  on  o I d-sty  |  e  procedural  programs  or  on 
users  of  the  shiny  new  features,  In  doing  this*  we  wanted  to  retain 
th®  block  structur6  rules  of  A|go|,  since  these  rules  ar#  generally 
familiar  to  programmers  and  Drovide  a  useful  means  of  determining 
which  data  Is  to  be  shared, 


J25cJTeJ3"§r8fiISi5Kesh5IS.?y°eSS  f S?m?SSal¥f riSS^'SgzSS?  mfSh|Sj£T 

a  Drocess  Is  essentially  a  procedure  activation  which  has  . b$en  given 
Its  own  run  time  stack  and  which  thus  does  not  have  to  return  before 
the  Process  that  Invoked  It  can  continue,  SaIL  Procedures  normally 
m6ke  up- 1  eve  I  references  v|a  a  "static”  (lexical  nesting)  chain 
maintained  for  that  purpose  In  the  stack,  when  a  procedure  Is  to  be 
eaU®d  as  an  lnde09ndent  process*  a  "process”  routine  first  sets 
space  for  a  new  stack,  It  then  sets  up  aoprooriate  Process  oontrol 
variables  In  the  new  stack  ar®a  and  In  the  "parent",  Finally*  the 
Procedure  Is  Invoked  using  the  new  stack,  when  this  procedure  Is 
entereo,  |t  will  set  up  Its  static  link  by  looking  back_a|ong  the 
static  chain  of  th#  calling  orocess  until  it  finds  an  activation  of 
Its  lexical  parent.  Thus*  different  prooesses  will  share  data 
belonging  to  their  common  ancestors, 


Many  of  the  applications  which  we  have  considered  do  not  permit  us  to 
Predict  Just  how  many  subprocesses  a  Process  might  wish  to  . soawn  or 
reaulre  that  several  processes  be  Instantiated  using  the  same 
Procedure  on  different  data,  Therefore,  we  have  chosen  to  "name" 
Processes  by  assigning  them  to  LEAP  items,  rather  than  by  using 
Procedure  names  or  some  soeclal  data  type  called  "Process”,  This 
aporoach  has  the  added  advantage  of  allowing  complex  structures  of 
Processes  to  be  bul|t  up  using  the  mechanisms  of  LEAP,  Mew  processes 
are  created  by  statements  of  the  formj 

SPROUTKttem  e*o  r  ess  I  o  n> ,  <p  r  oc  edu  r  e  ca  I  I  > ,  <oot  I  ons>  ) 

where  the  Item  soecified  by  Otern  expression>  Is  to  be  used  as  tne 
process  name,  the  <procedure  ca|!>  tells  what  this  Drocess  is  to  do, 
and  <ootlons>  is  an  integer  which  Is  used  to  soeclfy  how  certain 
orocess  attributes  are  to  be  set  up,  (If  the  <ootions>  parameter  Is 
omitted  pr  only  partially  specified,  SAIL  will  Provide  default 
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I 


» 


Until*'.  MSuiSoJ'ifJ;  *  to  noil  t«  board,  too.th.r  might 


ITEM  pl,p2,03j 


SPROUT(ol,grab( h» n dl#  hammer ) ) t 
SPROUT ( p2, g rab(h«nd2# rial  I  Ml 
SPR0UT(p3, I oakat < tvl# boar de ) ) { 


J0jN<  <ol»o2, d3>  >  f 

pound (hamme^,  naj  I,  boards)* 

i 


* 


iy-KtandS?;:!  i?rabi2srsl,h*r*r,,x:sst2t.b*  *» 

flenera  I , 


- ^ i y v « ^ «  mwi  rn«  ope 

on  fts  way  down  to  the  JOIN  statement. 


orqcesa  oi. 

o2»  and 
The  brooess 
In 


JO  IN ( <set> ) 

oaus«s  the  process  exeoutlnO  It  to  be  smoandari  .....t.  ...  -u 

. .  named  hy  the  <set>  h.!i  "i  '  » Uni7  1  ,|1  the 

Oound(h.mm.r,n.ll,b0.5S.)  win  not  ”.  o.lY.l  unt  rbl"*^1  .„;hU; 

n,a.  runnable),  at^g,”d<^S 

Is  invoked  either  tu  .  «iaak  f. ^  K  ^  1  ^  *  echeduterj  which 


brlor?tyrgnd8St lmgSgugntum! 

aoDroorlate  oot  on«  th«  cponii?.*  "  -us#r  epeolfles  otherwlee  by 
running  broo.ga,  whji,  th<  SPROUTlng  6roo.9*S?.v«?ta'to  ;»«dy"’Itgt*h' 

,oni:”r;;:;«i:h::.;3:  z°°"  r  h*v; 

ii:tinc<<::;  DOt,Bt'*liy  u>,,ui  *.  -fss4 


SPROUT<w.„d.fif.{,Wt?.!g.:(sgfiaomwj4 


)+RUN_M£) 
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C 


!h!  ?u'p?nt  Process  would  continue,  to  run.  and  wandapep  would 
languish  In  ready  status  until  everytblng  of  hlshe.  o.lolUy  had  been 
suspended,  r  r 

Processes  may  be  suspended  Op  terminated  via 

SUSP£ND<<proce33  Item  expe#ss]on>> 


and 


TERMINATE ( <ppoces3  Item  expression^ 

?hic5fJ°  J*3t  w£at  ?ne  m,0ht  expect,  Similarly,  SAIL  Provides  system 
functions  for  changing  a  orooess's  priority  or  Quantum, 

RESume^c  on  struct?  '  nt®r#ot  1  ons  ftra  diluted  by  the  use  of  the 


x-RESUMEUorocess  Item  express  I  on>,  <return  va|ue>,<ootlons>) 
whepe  <optlons>  Is  again  optional.  The  usual  effeot  of  RESUME  Is  to 
cause  the  currently  running  orooess  to  be  suspended  and  the  process 
specified  oy  <process  item  expression>  to  become  running.  If  the 
Process  being  resumed  had  suspended  Itself  by  means  of  a  resume 
statement,  then  It  w T I |  receive  <return  Va|ue>  as  the  value  of  the 
RESUME,  For  Instance, 


e 

Procedure  too i _getteP < itemvar  tool. type)* 

BEGIN 

ITEMVAR  too  1 1 


FOREACH  tool  I  tool  *  tool.bo*  A  type»too I stoo I ‘ type  DO 
RESUME (CALLER! THIS. PROCESS), tool )J 
END  l  ' 


I 

SPROUT  ( to«*NEW,  too  l.getter(screwdrlver),  SUSPEND  HIM) 
DO  sd*-RESUME(tg,NIC)  UNTIL  f  I  ts(  sd,  screWi )  i 


TERMINATE* tg)  I 


In  tj  a  case,  the  tool  getter  orooess  "to"  will  be  Initialized  and 
Immediately  suspended,  Then,  the  RESUME! tg, NIC)  will  wake  It  uo  to 
find  one  sorewdrlveP,  which  will  be  assigned  to  Itemvar  "sd"  by  the 
RESUME!CALLER(THIS. PROCESS), too | ) ,  ( THI S_ PROCESS  and 
CALLER(<proold>)  are  system  supplied  routines  that  return  the  crocess 
items  for  the  currently  running  process  and  for  the  orooess  that  last 
awakened  process  <Dropld>«  resoeot  I  ve  |  y , )  Later  on,  we  w||j  discuss  a 
somewhat  cleaner  solution,  using  matching  procedures,  to  the  problem 


U 


Us!a„f?r  .tl?ls  '  I  lustration.  W9  w|||  also  show  how  the  Intsporoons*? 
e°mjun^catlon  fag! lltTe?  of  the  language  may  be  used  to  handle  the 

oroblam  0f  what  t0  d0  if  t0ol.fl*tt«p  runs  0ut  0f  t00ls, 

FOREACH  STATEMENTS 

FQREACHa!!HJ*iIlJ  th*  LEAP  associative  store  Is  the 

of  I!  J*  A  FiR£iCH  *tat«.»ment  consists  of  a  "binding  list" 

rln  ill  [**  !  ,  ’associative  contaxt"  and  a  statement  to  be  Iterated. 
Consider  the  following  example. 


FOREACH  9p#D#c  I  parent  •  c  3  p  a  parent  •  p  =  gp  DO 
,  make  grandparent  •  c  S  gp; 

Jj„th  ,ThfX-nlp|e. th®  bJndlnfl“  I  1st  consists  of  the  Itemvars  "gp",  "o", 
-C  ®ssoc I  at i ve  context  consists  of  two  "elements",  "oarent  •  c 

Make  *  statement r6n*  *  °  5  9°“ ’  The  st,t,,”,nt  “>  "•  It.f.t.d  I,  th. 


Initially  all  three  Itemvars  are  "unbound".  That  To.  thav  am 

n?  '*:■  v,'u,t  sln°*  *?<  ;<>"“•  s^oS!!!?  h: 

I  ir.  n  parent  •  c  =  p  represents  an  associative  searoh,  The  LEAP 

the!!Pa!J0ih  J  Instructed  to  look  for  triples  oontalnlng  "parent"  as 

,f0  Ib  !•  f,ndlnfl  auch  a  triple,  the  Interpreter  asstans 
tne  ooject  and  value  components  to  "c"  and  "p"  respectively.  We 

U^niyVa  thh  naIt  ,*l9,n*nt  ’’parent  *  D  5  gp",  In  this  element  there 
JhJ  hiUHf°Un?v  la  not  unbound  even  though  It 

.s  '  pC  d,ndlng  hst  because  It  was  bound  by  a  preceding  e|eme0t, 
1.  ,<Tad#/0r  tr]ol0S  w'th  "parent"  as  their  attrlbute  and  the 

current  b'ndlng  for  "B»  as  their  object,  If  such  e  triple  Is  found, 

executed1'8  co^°mnent  ,a  b0Und  "OR"  and  the  MAKE  statement  Is 
executed.  After  execution  of  the  MAKE  statement,  the  LEAP 

"  1  "baCk  UD"  *nd  attemfit  to  find  another  binding  for 

gp  and  then  execute  the  MAKE  statement  again,  When  the  Interpreter 
ari  t  0  fnd  another  bind  ng.  It  bagks  up  to  the  preoeding  element 
ana  trys  to  find  other  bindings  for  "o"  and  "c".  Finally  when  ail 
triples  matching  th,  pattern  of  th,  first  ,|,m!nt  h,v#b,,n  tried! 
the  execution  of  the  FOREACH  statement  Is  oomplete, 

1  , F0RE ACH  elements  oonslsted  of  either  trials  searches. 

?!:  "0,rber*h  O’  or  boolean  expressions  not  defendant 1  on  SnbSSnd 

bind  .^inboCid  tt;;vj;.”0rehe8  *"d  Mt  “"owed  to 

SMcS°i'ei°K!t™??h?n3',“DrS^d8r,>B|sdl!?-'|IITrJr5  °8iiT?,nap?^jaj?§ 

*  I  Parameters,  These  parameters  are  not  necessarily  bound  at  the 
time  the  procedure  is  culled,  if  the  Procedure  oannot  Mnd  bindings 


for  Its  unbound  BINDING  parameters#  It  FaILs#  causing  the  LEAP 
Interpreter  to  beck  up  to  the  previous  element  within  the  associative 
context  of  the  FqREACH,  If  It  SUCCEEDS#  bindings  for  the  unbound 
parameters  will  be  returned#  Tbe  matohln?  procedure  Is  aotually 
SpROUTed  as  a  coroutine  process#  SUCCEED  and  TAIL  are  essentially 
forms  of  RESUME  which  return  oontrol  to  the  caller  with  the  values 
TRUE  and  FALSE  respectively,  FAIL  also  causes  the  matohlno  procedure 
Process  to  be  TERMlNATEd,  When  tbe  raatohing  procedure  Is  called  by 
"backup",  It  ts  merely  RESUMEd.  Thus#  the  entire  environment  In  te?ms 
of  the  procedure's  local  variables#  stack,  etc,#  Is  the  same  as  when 
the  procedure  executed  the  previous  successful  return,  The  matohlng 
Procedure  may  continue  from  tbe  point  at,  whloh  It  left  off, 
generating  new  bindings  for  Its  unbound  parameters,  In  many  respects 
matching  procedures  ape  similar  to  the  IPL-V  "generators"  whloh  have 
appeared  In  varied  forms  In  other  Problem-solving  languages, 

To  aid  in  “the  binding  operations  we  have  orovlded  predicates .  to 
determine  If  a  specific  parameter  Is  unbound  for  this  oall  of  the 
Procedure,  We  also  have  Introduoe  a  new  form  of  the  FQREACH  statement 
which  conditionally  adds  Itemvars  to  Its  binding  list,  Consider  the 
the  following  example  of  the  new  formi 


MATCHING  PROCEDURE  too  I  .getter (  ?  ITEMVAR  tool#  toolltyoe)) 
BEGIN  FqrEaCH  ?  too  I #  rtool.type  i  tool  *  tool.box  a 

typeetoc I stoo I .type  DO  SUCCEEDl 

FAIL! 

END ) 


0 


The  binding  list  of  the  FOREACH  would  contain  "tool"  only  If, "tool" 
were  unbound,  Similarly  It  would  oontaTn  ,Ttoo  I  _fyoe"  Tf  "tool.type" 
were  unbrund,  The  action  of  the  matching  procedure  Is  to  find  a  tool 
If  the  tool  Is  unknown  but  the  type  is  knowni  find  the  tyoe  If  the 
tool  Is  known  but  the  tyoe  Is  not*  verify  that  the  tool  Js  of  the 
roaulr«d  tyoe  If  both  ara  knownl  or  search  through  the  toolbox  and 
return  too  I , too  I .type  pairs  If  neither  tool  nor  type  Is  known,  The 
actual  semantics  is  determined  by  which,  if  either#  of  the  Darameters 
are  bound, 


Unfortunately  In  general#  matching  procedures  with  more  than  a  single 
Potentially  unbound  parameter  are  not  so  easy  to  code#  The  user  may 
have  to  provide  ud  to  2»N  different  code  sequences  to  handle  the 
various  combinations  of  N  BINDING  Itemvars, 


To  illustrate  ope.  class  of  uses  of  matching  procedures  let  , us 
consider  the  following  problem,  We  are  given  a  set  of  cube  shaped 
blocks  of  varying  sizes  and  are  reouested  to  olck  a  subset  of  the 
blocks  such  that  when  stacked  they  will  form  a  tower  cf  a  given 
height.  Assume  that  we  w|||  represent  a  cube  by  an  I t«m  whose  datum 
Is  the  height  of  the  cube,  We  may  easily  solve  this  oroblem  by  using 
a  recursive  procedure  "findl" , 


S 
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RECURSIVE  BOOLEAN  PROCEDURE  flndl  (SET  bsat»  INTEGER  dlffj 

REFERENCE  SET  ana); 

begin  INTEGER  ITEMVAR  newb! 

FOREACH  newb  I  newb  6  bset  a  (Mnewb)  $  Ji/f  J° 

IF  (a(newh)  =  d I f f >  v  f I ndlC bset-<nswb> . d I f f-*(newb> »*ns> 
THEN  BEGIN  PUT  newb  IN  answer iRETURN(TRUE)  END! 

RETURN ( F  ALSE ) J 
END; 

no-  l-t  at  *  slllMIK  different  « 

-]eh  to  ■fflutt.niouii-y  b“|  H  fr?m  *  5,1  1  *  *f  j " J 

G*  I  J  In*  "Mnfli11  t  w  I  c  # .  *  I  rst  with  th*  entire  •  o'  b  I  noke  1 or  !  ' 

tie  first  tswar #  tht*  -Tth  tht  Mittlnlng  hi '•4||! , 1°' UK!*  "Sift  "  , 

nat  *orw.  Though  there  i»ey  s^lst  msny  aoislbl*  lUbaeti  wM  in  •'ll 
for*  the  first  towor,  "f I ndl«  will  always  return  the  s§me  oie  even 
though  It  Is  possible  to  construct  the  second  tower  op|y  \l  * 
different  subset  bf  the  blocks  were  ohosen  for  the  f r 8* -elt2W,IldFSl 
exairo  I  e ,  |f  the  set  of  blooKs  consisted  of  sites  1»  4»  and  5  and  we 
were  to  construct  towers  of  heights  5  and  4.  "Hndl"  would  construct 
th®  first  tower  using  blooks  1  and  4  and  thus  be  unable  to  construct 

the  second  tower, 

Now  let  us  see  how  we  wpuld  use  matching  procedures  to  ovsroome  this 
ojoblem,  Let  us  write  the  matching  procedure  to  solve  a  single  tower 

Problem  [13, 


MATCHING  PROCEDURE  f I nd2  (SET  bsetl  INTEGER  height; 

?  SET  ITEMVAR  ans>) 

BERECURSiVE  PROCEDURE  aux  (SET  all  INTEGER  dlff)J 
BEGIN  INTEGER  ITEMVAR  neWhl 

FOREACH  n«wb  1  n*wb  *  si  *  (9(newb)-  S  dlff>  00 
BEGIN  PUT  newb  IN  Mans)  I 
IF  (S(newb>.  dlfr)  THEN  SUCCEED 

ELSE  jux ( si- (newt) i d I f f "9 ( newb) ) I 
REMOVE  newb  FROM  9(ans)| 

ENDi 

end; 

an8  -  NEW ( ( ) ) I  COMMENT  new  Item,  The  empty  set  Is  datum! 
aux( bset»  he  1 ght) I 

fail; 

end; 


To  caM  the 
statement ! 


matching  orooedur®  we  would  elmply  have  a  FOREACH 
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FOREACH  ans  I 


flnd2<b|ooksetitoe|ght,ens)  DO 
cr lnts«t<»<ana) )J 


This  is  clearly  eoujvalent  to  the  solution  Given  above 
However  now  consider  the  two  tower.  c*se}i 


for  "ftndl". 


FOREaCH  ansl»ans2  I  f I nd2( £> I ockset, he i ghtl, ansi ) a 
f  I  n<j2(b  lock  set- 8(  ansi  heigh  t2,ans2)  DO 
or  1 ntsets( 8<ansl) , 9(ans2) ) | 

This  will  find  a  solution  If  any  exists,  because  If,  after  finding  a 
solution  to  the  first  tower,  It  |s  Imocsslble  to  find  a  solution  to 
the  second  problem,  we  backup  and  find  a  different  solution  to  the 
first  tower  and  then  try  the  seoond  again, 


An  Interesting  distinct 
"finds"  nay  be  found.  Not 


on  between  the  programs  for 
ce  that  "find!"  only  returns  tc 
after  "unwinding"  the  recursion,  thus  allowing  the  answer 
constructed  as  the  recursion  Is  being  "unwound”  within  a 
call,  with  "flnd2",  however,  the  Drooedure  m ?'j  "return" 
while  It  Is  still  deeoly  nested  In  recursion  and  thus  the 
must  be  constructed  before  the  next  recursive  call  of  "aux" 


"flndl"  and 
its  caller 
set  to  be 
sucoessf u  l 
or  succeed 
answer  set 
Is  made. 


We  envision  that  matching  procedures  will  be  used  to  simulate  n-ary 
relations,  serve  as  Generators  of  moves  or  strategies,  as  well  as 
simply  aid  In  the  ood|ng  of  complex  associative  contexts, 


INTERPROCESS  COMMUNICATION 

In  complicated  systems  .sueh  as  the  Stanford  Hand  Eye  system,  where 
ther«  are  many  cooperating  processes  present,  one  would  (1 K o  to  have 
a  mechanism  by  which  an  occurrence  In  one  process  can  Influence  the 
flow  of  control  In  other  PrOoesses,  Such  occurrences  freayentj'y  fall 
Into  several  basic  groups,  with  perhaps  some  distinguishing 
information  associated  with  eaob  occurrence  of  a  given  type,  In 
assigning  Interprocess  communication  facilities  for  SAIL  we  wanted  to 
maWe  It  easy  for  the  user  to  distinguish  among  happenings  of  the  same 
genera!  type  and  to  define  for  hlmse|f  Just  how  each  type  Is  to  be 
hanoleo,  we  have  chosen  an  "event”  mechanism  which  is  real  1 v  a 
fairly  general  message  processor.  Any  Item  may  be  used  as  an  "event 
notice",  or  message,  and  each  type  of  event  in  a  program  Is 
represented  by  an  item,  With  eaoh  such  event  type,  SAIL  associates: 

1,  a  "notice  queue"  of  items  which  have  been  "caused”  for  this  event 
type . 

2,  a  "wait  queue"  of  processes  which  are  waiting  for  an  event  of  this 
type , 


* 


ft 


O 


3,  Procedures  for  manipulating  the  queues, 
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The  two  essential  actions  associated  with  any  event  type  are 
CAUSE(<event  tyD®> * <not  I *e  1 1 o rt,  >,<ootlons>) 

and 

lNT[rRROGATE(<ev#nt  type>»<oPtlons>) 

where#  as  elsewhere,  <opttons>  may  be  left  OJt  If  the  default  case  Is 
desired, 

The  statement 


CAUSE  <  typel , ntc ) 

would  cause  SAIL  to  look  at  the  wait  Queue  for  typel,  If.  the  aueue 
Is  empty  *  then  "ntc"  would  be  put  Into  typel's  notice  queue. 
Otherwise,  a  Drocess  would  be  removed  from  the  wait  aueue  and 
reactivated,  with  "ntc"  as  the  awaited  item, 

If  a  process  executes  the  statement 

1 tmv* INTERROGATE < typel) 

then  tne  first  Item  In  the  not|oe  aueue  for  tyoel  would  be  removed 
from  the  queue  and  assigned  to  itemvar  Itmv,  If  the  aueue  Is  empty, 
then  itrrv  would  be  set  to  the  special  I  tern  NIC,  If  a  Process  wants 
to  wait  for  an  event  of  a  given  type*  It  may  do  so,  as  In 

Itmv- INTERROGATE (typel, WAIT) 

In  this  case,  If  ths  notice  aueue  Is  empty,  then  the  process  will  be 
suspended  and  put  onto  the  Walt  aueue  for  typel, 

Similarly, 

I tmv- INTERROGATE (typel, RETAIN) 

causes  the  event  notice  to  be  retained  In  the  notice  aueue  for  tyoel. 

This  event  mechanism  should  prove  useful  In  problem  solving 
applications  in  which  processes  are  sprouted  to  consider  different 
actions,  An  "or"  node  In  a  goal  tree,  for  example,  might  be 
reDrOsented  by 

« 

* 

• 

SPROUT(pl,nal | ( sucev^, boards))! 

SPR0UT(D2,g|ue(sucevt, boards))) 


SPRuUT<D3iScrew(sucavt#boards)}> 

w!nnef‘-INTERRQGA'rE<sucevt*wAlTU 

FOREACH  o  |  ot  <pl * oZ* p3 )  a  p*wlnner  DO  TERMINATE ( d ) j 
I 


When  a  branch  discovers  that  It  has  succeeded,  It  can  execute  a 
statement  I  I ke 


CAUSE(sucevt#TH!?_PROCESS> | 

*h!ch  would  announce  success  and  cause  Its  parent  to  terminate  Its 
1 6 s s  successful  brothers. 

Events  give  us  a  means  by  which  some  disoovery  made  by  one  process 
can  be  made  to  "unstick"  some  other  orocess  which  has  ootten  Into 
troub|e,  Lets  consider  our  tool  getter  again, 

PROCEDURE  tool  getter ( ITEMVAR  too|_type)| 

begin 

I  TEMyAR  too  I  i 

FOREACH  tool  I  too  I *too I b°x  A  type*too I =too I  type  DO 
RESUME (CALLER (THIS  PROCESS) , too  |  )  J 
DO  too  |  •'INTERROGATE!  too  I  .found.  WAIT) 

UNTIL  typaetoo | =too | -type j 
RESUME (CaLLER(TH I S.PROCESS), too ! )  l 
END; 


If  the  FOREACH  statement  falls  to  find,  «  woi.  oi  mu  corr««» 
then  tocT_getter  will  be  suspended  until  some  process  causes  an  event 


a  tool,  of  the  correct  tyoe, 

:hen  t o o  I  _ g e t ^ 

of  type  tool.found.  using  the  an  Item  representing  tool  rs  the  event 
notice,  Suppose  that  our  Proeees  "wanderer”  has  finally  gotten  a 
chance  to  run  (everything  of  higher  Priority  being  stuck)  and  that  It 
does*  In  fact,  stumble  across  a  sore wd river*  which  It  knows  to  be  a 
k i na  of  tool,  It  might  then  do  something  like 


make  typeeth I n9=screwdr I ver J 
PUT  thing  IN  tool-boxj 

C AUSE ( too |  found, thing, TELL  EVERYONE+DONTSAVE ) l 


This  would  cause  every  process  waltjnfl  on  the  event  "too  I  ..found”  to 
be  awakened,  (If  n0  Drocess  Is  waiting,  the  notice  will  not  be  saved 
on  the  notice  aueue.)  This  would  wake  ud  whomever  called  tool.oetter, 
which  would  then  see  If  It  oan  use  the  "thlno”. 


SjMVmWi  fne,o!>iScIlBSt?h|lsoouT§0S«  do°RS  b?'.  sfSSU*1 

lNTERROGATEs  each  event  tyoe  In  a  list,  unf crtunate  I  y,  if 


dossJ b la 
loop  which 
one  wishes 
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to  wait  for  ar  occurrence  within  a  fllven  set  of  events?  this  doesn't 
work  very  well,  since  an  attempt  to  wait  for  one  event  type  will  keep 
th®  other  types  from  b®1n3  seen,  Therefore,  SAIL  allows  a  Drocess  to 
ask  about  a  set  or  list  of  event  types  directly,  as  In 


I tmv-INTERR0GATE(ev.type. 1 1 s.WAJT+RETAIN) 

M."Ail|gI  £s.uS3a u8 ; < I r °§T Tf , a* 1  f I »!*■  If  .fjl 

any  o f  wait  aueue  entries  Is  sfcvlced  {All  wait  queue  entries 
this  request  wl  |  I  be  deleted,)  If  It  Is  necessary  to  know  Just  which 
type  was  responsible  for  a  fllven  notice,  the  option  SAY_whICH  may  be 
usep.  Suppose  the  statement 


of 
oon.as 
for 


ltmv*-INTERROGATE(ev_type_|ls»WAIT+SAV_  WHICH) 


returns  item  "notjc",  whleh  was  caused  as  an  event 
catastro.he,  as  Its  value.  Then  the 

EVEnT.t YPE*notl c=catastrophe  will  be  made  by  the  system, 


of  type 
association 


Thus?  One  way  to  proQram  an  "and"  node  within  orocess  "foo"  mlflht  be 
something  I  TRe 


SPROUTlpl, fetch (hammer , hand!, eucevt, f a  I  levt) > J 
SPR0UT(p2, f etch(nal I , hand2, suc»vt, fa  I |evt)>) 

• 

SPROUT ( pn, l0okat( cvl,board6,suoevttfa|  ievt))l 
FOR  I  -  1  STEP  1  untl I  n  DO 
BEGIN 

p-INTERROGATE( ((fa  I  I evt i sucevt) ) #  WAI T) | 

IF  EVENT* TYPEep=fa| IfVt  THEN 
BEGIN 

MAKE  f al I ure^caueeefoosfil 

FOREACH  plot  <(pl«p2i . . . »on>>  DO  TERMINATE ( D )  J 

CAUSE(foo3.f«l lure-event »f oo)  { 

SUSPEND ( f oo ) I 
END; 

END) 

CAUSE ( foos_suc cess .event, foo)  I 


Were,  It  Is  assumed  that  eaoh  process  Is  to  take  responsibility  for 
making  "life  or  death"  decisions  refluardlnfl  any  suborocesses,  As 
soon  as  one  jf  ths  p|  reports  failure,  foo  will  terminate  ell  Its 
"children"  (whose  aDPoin^ed  +  esks  have  become  polntless>  rSDor^  >t3 
own  failure,  and  suspend  Itself,  If  all  the  ol  report  suocess,  then 
foo  w|||  do  | Ikewj  se, 


Events  may  be  used  toflether  with  matohlna  procedures  to  do  deferred 
updating,  as  Is  shown  by  the  following  example,  A  matohlnc  procedure 
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t„.  fqneaCh  »uee**<t».  Oen.lMr  «•  .f*  ^'"S  “!  !!(  I;l*'f  hi  I- 

Iraim,  Per  **e*  *»*ber  J?  th* J  llgBunt  M  M  'deeen't  hi»t 

zs. i:s.  ,:!::.T.ti.-i;i;H  «;* tsntt $? 

“"'MST-nlSStwi"  ill"*  "••"I  “h,n  "  »,'"sn  0,t’  ’  bl“k  '"rk’ 

he  t^en  becomes  a  suSDect. 


SET  badguys J  LIST  suspect!  t  tcmu ar  *>. 

MATCHING  PROCEDURE  | I nk«d  <  8 1  NO  1 NG  ITEMVAR  x)| 

begin 

procedure  update* 

BEGIN  INTEGER  ITEKVaR  y.M 

while  true  do  , i a i T \ • 

BEGIN  f«- INTERROGATE!  I  i nked«k» WAIT) I 
PUT  r  IN  badges! 

8(f  )  ••  a  c  f  )-2l 

FOREACH  y  I  ANY  *  x  =  y  DO 

BEG|p  a(y)  ^^TNEn’pUT  y  IN  suso»Ct  AFTER  -I 
END  j 

END  I 
END  1 

z*NEW  |RS^0UT  (  z  i  uodate )  I 

FOREACH  X  |  X  t  auso«ct  00 
SUCCEED* 

TERM  I  NATE ( Z ) J 
F  A I L  I 
END  j 


a  lnformer»o«r9on5f InR  DO 
BEGIN  CAUSE ( 1 1 nkedok, f I nk ) I 
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ta*—*-**- 


This  simple  example  do»s  of  course  not  re»||y  reouire  either  matching 
Droceaures  or  the  ^event  mechanism  to  cause  the  updating,  but  the 
technique  it  Illustrates  should  be  quite  valuable  In  more  complicated 
s i tu®t Ions, 

55fHd!?  8**#  WH!  ««rsu:jieisss 

they  are  not  aulte  right.  For  Instanc#,  a  Drooess  might  want  to  wait 
ufl  Han  ®ve"t  on|y  If  no  otber  Process  Is  already  waiting  for 
that  event.  Instead  of  trying  to  provide  a  special  option  to  cover 
every  Possible  contingency,  we  have  Instead  provided  a  set  of  queue 

I  *  ?Kr1?rS^rfrrniat  v8s  -w,th  whf°h  th®  us®r  «an  "rfta  his  own  CAUSE 
and  INTERROGATE  Procedures,  To  substitute  his  own  orooedure  for  the 
one  Provided  by  SAIL*  the  user  makes  an  association  of  the  form 

CAUSE_PROCetypal=new_ cause. proc 


or 


lNTERROGATElPROC«typel  =  new. I nt_p  roo 


whePe  tycel  |s  the  event  type  and  new. cause  proc  and  new  IntDroc  are 
Procedure  Items  b0und  to  the  substitute  procedures.  TheJe  5focedu?es 

^:.as1J,,*TomTc"  operations*  and  will  be  allowed  to  finish 
.  ;  Inter  r  up 1 1  on ,  In  particular,  any  CAUSEs  or  changes  in 

n!«JeSun^MtU?/9ai!!Ste-  by„  SUoh  ?  Procedure  will  not  actually  take 
Place  until  after  the  prooedure  exits,  This  "Interrupt  level"  tur'ns 

out  to  be  quite  useful  and  permits  one  to  wr1te  Interrupt  handlers 

•  *at  not,c0  of  som®  event*  do  what  they  can.  and  then 

w^!f'Jrn  °r  e|se  caU8e  •"  ®vent  that  will  trigger  some 
stronger  condition, 


I 


> 
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CONCLUSION 

Each  of  the  features  desorlbed  In  this  papaP,  was  Intended  to  solve 
Particular  programming  probjams.  W*  htvs  not  yet  had„.suf  f  I  o !  ant 
Practical  experience  with  the  new  system  say  with  certainty  that 
they  ere  the  the  right  ones,  Thsre  Is  a  great  deal  of  work  on  these 
Problems  in  several  laboratories  and  new  Issues  are  bflng  raised 
fluently.  We  do  feet*  however,  that  the  basic  solutions  suggested 
here  w|||  prove  useful  and  that  they  do  significantly  extend  the 
capabilities  of  Mgbl-llke  languages, 
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